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(54) Procede de gestion de r heritage multiple d'objets persistants et partagds. 



@ Ce proc6d6 de gestion de I'h6ritage multiple est congu pour etre appliqu6 dans un systeme ou £ un 
langage £ objets persistants et partag6s. Selon ce proc6d6, le fonnat d'un objet est maintenu inchang6 
lors de son chargement de I'espace persistant vers I'espace virtuel. En outre, chaque classe engendrant 
un objet est assoctee d un identificateur de la classe constant dans toutes les applications utilisant la 
dasse ainsi qu'S travers toutes les recompilations. La structure de I'objet est ainsi ind6pendante de 
I'adresse d'implantation en m6moire et du code de la classe g6n6rant cet objet Enfin, selon le present 
proc£d6, un chemin d'adressage permettant la gestion de rh6ritage est impost au travers de d*rff6rentes 
tables. 
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La presente invention concerne un precede de gestion de rheritage multiple dans un systeme ou un Ian- 
gage & objets persistants et partages. 

De mani6re g6n6rale les langages ou les systemes £ objets s'appuient sur la notion de classe qui est une 
entite permettant de g6n6rer et de manipuler des objets. Une classe definit d'une part la structure des objets 
qu'elle va engendrer £ travers la definition d'attributs et d'autre part le comportement desdits objets £ travers 
la definition de mSthodes. En outre, la possibility de definir une relation d'heritage entre diff6rentes classes 
est une caracteristique essentielle de ce type de langages, cette relation pouvant et etant g6n6ralement une 
relation d'heritage multiple. II est parie d'heritage multiple lorsqu'une meme classe est d6f inie par rentage 
de plusieurs autres classes. Pour m6moire, une classe qui herite d'une autre classe est communement appeiee 
une "sous-classe", la classe h6rit6e etant alors consid6r6e comme une "super-classe" de la sous-classe. Ega- 
lement, dans la relation d'heritage relativement a la notion de classe il est couramment distingue deux compo- 
santes. Une premiere composante relative £ I'h6ritage structurel : la structure d'un objet d'une classe donn6e 
se compose des attributs d6f inis dans cette classe ainsi que de I'ensemble des attributs des classes heritees 
directement ou indirectement La seconde composante est relative a I'heritage comportemental les methodes 
permettant de manipuler un objet sont celles def inies dans sa classe ainsi que toutes celles def inies dans les 
classes heritees directement ou indirectement. A cet aspect s'ajoute g6nSralement la possibilite de surcharger 
pour une sous-classe, le code d'une methode definie dans une super-classe. Cette fonction necessite alors 
un m6canisme de liaison dynamique & ('execution appeie par I'homme du metier "late binding". 

Lorsqu'un tel langage & objets (par exemple C++) est compile, le compilateur doit definir implantation 
memoire des objets ainsi que I'adressage des attributs et des methodes associ6s. La gestion de I'heritage 
multiple d'objets devient assez rapidement complexe et pose des probiemes, mais dans un contexte d'objets 
non persistants il existe une technique eff icace, mise en oeuvre avec le langage C++, qui permet de r6soudre 
des probiemes pos£s par I'heritage multiple. Cette technique est decrite par M.A. Ellis et B. Stroustrup dans 
The Annotated C++ Reference Manual", Addison- Wesley 1990. 

Malheureusement cette technique presente un inconvenient majeur car elle devient ineff icace et done inu- 
tilisable lorsqu'il est d6sir6 I'appliquer dans un contexte d'objets persistants (les objets survivant £ la fin de 
I'execution du programme qui les a cr66s) et partag6s (plusieurs programmes accSdant simultan6ment un 
meme objet). 

La presente invention a pour but de rem6dier aux inconv6nients pr6cit6s et propose un precede de gestion 
de I'heritage multiple qui peut etre utilise aisement et eff icacement dans un systeme ou par le g6nerateur de 
code d'un langage d objets persistants et partages. 

Pour cela, le precede de gestion de rheritage multiple mention ne dans le preambule est remarquable en 
ce que le format d'un objet est maintenu inchange lors du chargement dudit objet de I'espace persistant vers 
I'espace virtuel, chaque classe engendrant un objet etant associee a un identif icateur de la classe constant 
dans toutes les applications utilisant la classe ainsi qu'S travers toutes les recompilations, la structure de I'objet 
• etant ainsi independante de I'adresse d'implantation en memoire et du code de la classe g6n6rant cet objet 
alors qu'un chemin d'adressage permettant la gestion de ('heritage est emprunte au travers de differentes ta- 
bles. 

En outre, le procede de gestion de rheritage multiple selon le presente invention est remarquable en ce 
que, pour implantation des objets en memoire, chaque classe est associee & une partie qui est identique pour 
tous les objets appartenant d cette classe, chaque partie etant composee de deux sous-parties, une premiere 
sous-partie comportant un identif icateur de la classe r6elle qui a engendre I'objet identificateur utilise comme 
indice dans une table de classes donnant le point d'entree du chemin permettant la gestion de rheritage et 
une seconde sous-partie renfermant retat d6f ini par la classe ayant engendre l f objet, rensemble des attributs 
d6f inis par ladite classe etant regroupe dans ledit etat 

Ainsi, selon rid6e de invention la plus grande partie du traitement est oper6e statiquement, c f est-£-dire 
au moment de la compilation et le chemin d'adressage est 6labor6 pour autoriser avec certitude I'appel de la 
methode adequate au moment de l'ex6cution ( cette technique garantit que cette methode peut dtre appliquee 
de nouveau sans operation pr6alable sur I'objet qui est en train d'etre charge. La structure de I'objet est in- 
dependante de son implantation memoire, done de I'adresse & laquelle il va etre implante et independante du 
code de la classe qui a engendre cet objet 

La description suivante en regard des dessins annexes, le tout donn6 £ titre d'exemple non limitatif, fera 
bien comprendre comment invention peut etre r6alis6e. 

La figure 1 pr6sente, pour un exemple d'heritage multiple donne, une solution de I'art anterieur pour des 
objets non persistants et non partages. 

La figure 2 propose, pour le meme exemple d'heritage multiple, la solution selon invention applicable d 
des objets persistants et partages. 

Apartir de I'exemple d'heritage multiple presente sur les figures 1 et 2 et pour une meilleure apprehension 
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de Tid6e de Tinvention, vont etre tout d'abord d6crits quelques probtemes M6s £ la gestion de Theritage multiple. 
En particulier, il ressort de cet avant-propos, qu'il n'est pas possible de def inir une implantation memoire pour 
les objets concern6s, qui permette de determiner statiquement. c'est-£-dire au moment de la compilation, 
I'adressage des attributs d'un objet. La mSme constatation r6sulte de Texamen de Tappel des methodes sur- 
5 chargees. 

Avec Texemple simple choisi et represents sur les figures 1 .a et 2.a, quatre classes C1 , C2, C3 et C4 sont 
d6crites. Les classes 02 et C3 sont en relation d'rteritage direct avec la classe C1 . La dasse C4 est en relation 
d'rteritage multiple direct avec les classes C2 et C3 et indirecte avec la classe C1 par Tinterm6diaire des classes 
C2 et C3. Chaque classe Ci def init ses propres attributs qui sont regroup6s dans un 6tat Ei. Ainsi, sur les figures 

10 1 .a et 2.a les attributs des classes C1, C2, C3 et C4 sont r£unis respectivement dans les etats E1 f E2, E3 et 
E4. Les methodes mi proposees pour chaque classe dans Texemple sont les methodes implantees par la clas- 
se, ainsi en est-il dans Texemple des methodes ml, m2, m3 et m4 implantees par la classe C1, des methodes 
ml et m5 implantees par la classe C2, des methodes m2 et m6 implantees par la classe C3 et enfin des m6- 
thodes ml, m3, m6 et m7 implantees par fa classe C4. 

is Le premier problems rencontre est reiatif a I'adressage de i'etat Ei. En effet, 1'impiantation m6moire d'un 

objet correspond a une zone memoire dans laquelle se trouvent tous les attributs composant Tobjet. Cette 
zone contient done tous les etats Ei des classes auxquelles appartient cet objet Ainsi, dans Texemple choisi, 
un objet de la classe C1 serait implante dans une zone contenant E1 , un objet de la dasse C2 serait implante 
dans une zone contenant E1 et E2 un objet de la dasse C3 serait implante dans une zone contenant E1 et E3 

20 et un objet de la classe C4 serait implante dans une zone contenant E1, E2, E3 et E4. Dans ce contexte une 
variable de type C3 dans un programme peut designer aussi bien un objet de la dasse C3 que de la classe 
C4. Or s'il est accede a retat E3 a travers cette variable, il est clair qu'il n'est pas possible de d6f inir statique- 
ment son adresse relative dans Tobjet Une solution pourrait conduire a r6server dans les objets de la classe 
C3 egalement la zone contenant T6tat E2 qui n'est pourtant pas utilise dans C3, c'est-S-dire qu'un objet de la 

25 classe C3 serait implante dans une zone contenant E1 , E2 et E3. Cependant cette solution ne peut etre va- 
lablement exploitee car une perte d'espace m6moire considerable serait engendr6e. Ceci est encore plus vrai, 
dans un contexte d'objets persistants car une telle solution obligerait a reconstruire des objets existants lors 
de certains ajouts de sous-classes. La premiere implantation proposee est done preferable du point de vue 
de Toccupation m6moire mais a pour principal inconvenient Tobligation de calculer dynamiquement Tadressaqe 

30 des etats Ei. 

Le second probieme rencontre est reiatif a Tappet de methode mi. En effet, Tappel de methode implique 
de determiner dynamiquement le code a appeler. Ainsi, en prenant la methode ml dans Texemple pr6cite et 
en appliquant cette methode k un objet d6signe et done manipuie a travers une variable V de type C1 (appel 
C++ du type "V-+m1"), il apparait que ledit objet peut appartenir indifteremment a la classe C1, C2. C3 ou C4. 

35 Suivant son type r6el qui ne peut etre connu qu'£ Texecution, la methode a appliquer n'est done pas la meme. 
Le present exemple peut s'illustrer comme suit : 
C1*v, *v1; 
C2 *v2; 
C3 *v3; 

40 C4 *v4; 

v1 = new C1 (); v2 = new C2 (); v3 = new C3 (); v4 = new C4 (); 
v = v1; v -+m1();/* appel de ml d6finie dans C1 V 
v = v1; v-+m1();/- appel de ml definie dans C1 */ 
v = v2; v-hti1();/* appel de ml d6finie dans C2 */ 
45 v = v3; v-fm1();/* appel de ml definie dans C1 */ 
v = v4; v-+m1();/* appel de ml definie dans C4 V 

Le probieme apparait ainsi dairement gn§ce a cet exemple parmi les quatre appels n v-»m1 ();" possibles, 
il existe trois cas d'ex6cution diff6rents alors que le compilateur ne peut interpreter cette situation que comme 
un seul cas. 

so Dans ce contexte, le langage C++ fournit une solution satisfaisante. Ainsi pour r6soudre les deux probie- 

mes cites ci-avant, le langage C++ utilise d'une part des pointeurs dans Timplantation m6moire de Tobjet pour 
Tacc6s aux etats h6rites et d'autre part des tables d'indirection appetes par Thomme du metier "tables virtuel- 
les" pour la resolution de Tappel de methode. 

Comme cela a 6te dit pr6cedemment, cette technique est explicitee par M.A. Ellis et B.Stroustrup dans 
The Annotated C++ Reference Manual", Addison-Wesley, 1990. L'exemple propose et decrit avec la figure 
1 .b permet de schematiser Timplantation m6moire, en vue de la gestion de Theritage, d'un objet C++ de la das- 
se C2 <Obj_C2) et celle d'un objet de la dasse C4 (ObLC4), conservant a Tesprit que, chaque classe Ci d6f init 
un 6tat Ei et un certain nombre de methodes dont certaines sont des surcharges (voir figure 1.a). 
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Pour Hmplantation m6moire le compilateur associe alors a chaque classe Ci (C1, C2, C3, C4) une partie 
Pi (P1, P2 f P3 et P4) qui est la meme pour tous les objets appartenant a cette classe que ce soit par appar- 
tenance directe d'un objet de classe Ci ou par I'h6ritage d'un objet d'une sous-ciasse de Ci. Toutes les parties 
Pi contiennent trois sous-parties distinctes : 

5 - une premiere sous-partie qui correspond a un pointeur vers une table virtuelle (VT2.1, VT2.2, VT4.1, 

VT4.2, VT4.3, VT4.4) contenue dans fe code de la classe qui permet de g6rer I'appel de n'importe quelle 

methode (m1 t m2 m7) applicable a un objet de la classe Ci (C2, C4). Ce champ est le meme pour 

toutes les parties, i! est appe!6 et reference sur le dessin "vtbP. Chaque 6l6ment d'une table virtuelle 
contient deux champs, le premier 6tant un pointeur vers une fonction C implantant une methode C++ 

10 et le second, un deplacement pour calculer le pointeur sur la partie de I'objet a passer comme premier 

param^tre de la fonction C, ce paramfctre correspondant a la variable "this" utilisee dans le corps d'une 
methode C++. Ainsi par exemple la table virtuelle VT2.1 pointee par le champ "vtbl" de la partie P1 as- 
soci6e a la classe C1 d'un objet de la classe C2 (obj_C2) comporte quatre 6l6ments chacun relatif a 
une methode ml, m2, m3, m4 implantee par la classe C1, chaque 6l6ment contenant deux champs. Le 

is premier champ m1_2 du premier 6l6ment est ici un pointeur vers la fonction implantant la m6thode ml 

dans la classe C2 alors que le second champ d1_2 correspond au d6placement permettant de calculer 
le pointeur sur la partie P2 de I'objet de la classe C2. De meme par exemple, la table virtuelle VT4.3 
point6e par le champ "vtbl" de la partie P3 assoctee a la classe C3 d'un objet de la classe C4 (obj_C4), 
comporte cinq elements chacun relatif soit a une methode m2 f m6 implantee par la classe C3 soit a une 

20 methode surchargee ml, m3, m4 heritee de la classe C1. Le premier champ m1_4 du premier 6l6ment 

est ici un pointeur vers la fonction implantant la m6thode ml dans la classe C4 alors que le second champ 
d3_4 correspond au d6placement permettant de calculer le pointeur sur la partie P4 de I'objet de la clas- 
se C4. 

- une seconde partie qui correspond a des pointeurs vers les parties Pj pour toutes les classes Cj dont 
25 Ci h6rite directement, ces pointeurs 6tant appel6s "Pj_addr" et references @ (Pj). Par exemple pour la 

partie P2 : "Pl^addr" (@ (P1)) ou pour la partie P4 : "P2_addr w (@ (P2)) et "P3_addr" (@ (P3)). 

- une troisteme sous-partie qui correspond a I'Stat Ei d6f ini par la classe Ci, ce champ de Pi 6tant nomm6 
et r6f6renc6 "st". 

Pour la suite il est important de rappeler qu'une variable de type Ci, par exemple "Ci *V", pointe toujours 
30 vers une partie Pi, quelle que soit la classe reel I e de I'objet pointe. Ainsi, pour d6f inir la variable "C2 *V W (f ig.1 .b) 
V dSsigne Obj_C2, cette variable pointe sur le d6but de I'objet (d6but de la partie P2) alors que si V d6signe 
Obj_C4, la variable V pointe au milieu de I'objet, d6but de la partie P2. 

Apr6s avoir d£crit toutes les informations mises en oeuvre dans les objets C++ et a I'exterieur pour gerer 
la semantique de rtteritage virtue), il sera a present examine comment lesdites informations sont utilises pour 
35 calculer I'acc6s aux differentes parties de l'6tat Ei d'un objet ou pour I'appel d'une m6thode mi, il est suppos6 
dans Texemple suivant que les objets Obj_C2 et Obj_C4 sont dSsignes a travers un pointeur de type C2 conte- 
nu dans une variable V. 

Pour acc6der a l'6tat Ei d'un objet, le cout varie suivant le type du pointeur sur I'objet et la partie de T6tat 
a acc6der. Lorsqu'il s'agit de la partie correspondant au type de pointeur, I'acc6s ne coute dans ce cas qu'une 

40 indirection. C'est la cas pour I'accds a l'6tat E2 qui se traduit par "V-+st", pour I'objet Obj_C2 comme pour I'objet 
Obj_C4. Par contre s'il est d6sir6 acc6der a l'6tat E1, cela se traduit par "V-+P1_addr -»st", c'est-a-dire, que 
cet acc£s coOte une double indirection. En fait, il y a autant d'indirections plus une que le nombre de niveaux 
d'lteritage s6parant la partie pointee de celle de l'6tat a acc^der, par exemple pour acc^der depuis la partie 
P4 a l'6tat E1 : •P4->>P2_addr-+P1_addr->sr ou encore, "P4-> P3_addr-*P1_addr->st". 

45 Concernant I'appel d'une nrtethode mi, le cout est constant quelle que soit la classe dans laquelle la me- 

thode appelee est imptementee. En revenant au premier exemple (Obj_C2 et ObjL_C4 d6signes a travers un 
pointeur de type C2 contenu dans une variable "V"), pour un appel en C++ "V->m2 ()", de manfere 6vidente 
le code est le meme que I'appel se fasse sur I'objet Obj_C2 ou sur I'objet Obj_C4. Ainsi, dans cet exemple 
precis, I'appel se traduit par : 

so •( * (V-+vtbl[index(m2)].m) (V + V-*vtbl[index(m2)].d t ... 

La premiere expression (entre parentheses) permet la recuperation de I'adresse du code pertinent de la 
ntethode m2 dans la table virtuelle assoctee a I'objet : pour I'objet ObjLC2 f table VT2.2, m2_1, ou pour I'objet 
Obj_C4, table virtuelle VT4.2, m2_3. L'indice dans la table est calcul6 statiquement, il est a priori different pour 
chaque classe dans laquelle la methode est visible. La seconde expression permet elle, le calcul du pointeur 

55 v d6signant la partie sur laquelle travaille toujours la methode appelee : pointeur vers la partie Pj ici P2, de 
la classe Cj ici C2 qui def init la methode m2 appelee. Ce calcul est effectue en recuperant le deptacement par 
rapport au pointeur d'appel, ce deplacement etant stocke dans la table virtuelle, a l'indice correspondant a la 
methode m2 appel6e : pour I'objet Obj_C2, dans la table virtuelle VT2. 2, d2_1, ou pour I'objet Obj_C4, dans 

4 
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la table virtuelle VT4.2, 62J3. 

Dans le contexte d'un langage a objets compile travaillant en m6moire centrale la technique mise en oeu- 
vre dans cette m6thode s'avere assur6ment eff icace. Par contre, cette technique engendre de nombreux pro- 
blames lorsqu'il est d6sir6 I'appliquer a un langage manipulant des objets persistants et partag6s par plusieurs 
5 applications en cours d'ex^cution. 

Ainsi, dans ce nouveau contexte qui est celui pour lequel I'invention a 6t6 mise en oeuvre, deux principles 
difficult6s sont rencontrees, une premiere en ce qui concerne d'abord les pointeurs vers les tables virtuelles 
contenues dans le code des classes, cette technique pose en effet les problemes suivants relativement d'une 
part a la persistance et d'autre part au partage. 

10 Relativement a la persistance, il est irrealiste de chercher a garantir que le code d'une classe sera toujours 

charge a la meme adresse, ne serait-ce que parce que le code d'une classe doit pduvoir changer. La solution 
a ce probl6me pourrait resider dans le fait de changer les pointeurs "vtbl", chaque fois qu'un objet est charg6 
dans une nouvelle session, lorsque I'application s'ex^cute, mais cette solution est couteuse et v6ritablement 
complexe a mettre en oeuvre. 

15 En outre, relativement au partage, ii faudrait garantir que le code d'une classe est coupl6 et done attache 

a la meme adresse dans toutes les applications Tutilisant. La solution dans ce cas consisterait a stocker de 
maniere f ig6e le code des classes dans une librairie partag6e, mais cette technique ne peut Stre s6rieusement 
exploitte car elte se prete mal a des librairies dont le code doit justement pduvoir changer regulierement, la 
modification d'une librairie partag6e simultanement avec ('utilisation de ladite librairie par des applications en 

20 cours d'ex6cution 6tant impossible. 

Toujours dans ce nouveau contexte, une seconde difficulty est rencontree, cette dernfere principalement 
Itee a la persistance concerne les pointeurs vers les parties Pj des super-classes. En effet, il est essentiel de 
pouvoir garantir que d'une session a Tautre, un objet est toujours couple a la meme adresse virtuelle. La tech- 
nique d6crite ci-avant ne peut etre mise en oeuvre qu'a I'aide d'un fichier UNIX (marque d6pos6e de UNIX 

25 System Laboratories, Inc) dit (par I'homme du metier) "mappS", e'est-a-dire pour lequel des correspondences 
sont impos6es, ceci dans l'hypoth6se fort peu probable ou il serait possible de garantir que led it fichier est 
toujours couple a la meme adresse virtuelle. Une autre technique pourrait, sinon, consister a rafraTchir ces 
pointeurs lors du chargement de I'objet, mais cette seconde solution est encore une fois fort couteuse et 
complexe a mettre en oeuvre. 

30 Conform§ment a I'id6e de la pr6sente invention, dans ce contexte ou un systeme ou un langage a objets 

persistants et partag6s est utilise, le proc^de de gestion de ('heritage multiple est remarquable en ce que le 
format d'un objet est maintenu inchang6 lors du chargement dudit objet de I'espace persistant vers I'espace 
virtuel, chaque classe engendrant un objet etant associ6e a un identif icateur de la classe constant dans toutes 
les applications utilisant la classe ainsi qu'& travers toutes les recompilations, la structure de I'objet etant ainsi 

35 ind£pendante de I'adresse d'implantation en m6moire et du code de la classe g6n6rant cet objet, alors qu'un 
chemin d'adressage permettant la gestion de I'h£ritage est emprunte au travers de diff£rentes tables. 

Ainsi, selon cette solution revendiqu6e, il est propose un format pour des objets C++ persistants accom- 
pagne d'une technique de gestion de I'h6ritage permettant d'off rir toutes les r^ponses aux probl6mes propres 
au dernier contexte d6crits pr6c6demment. Son champ duplication couvre ('ensemble des langages persis- 

40 tants a objets ainsi que les systemes de gestion de base de donn£es a objets offrant une fonction d'heritage 
multiple similaire a celle du langage C++ (heritage virtuel et methodes virtuelles). 

II ne sera pas donne ici d'algorithme permettant de produire les structures de donn6es necessaires au 
mecanisme, ni meme d'algorithme de traduction d'un code source vers du code objet utilisant ces structures. 
Ces algorithmes sont en effet sp6cifiques de chacun des langages utilisant cette technique meme s'ils ont 

45 des caracteristiques communes que Thomme du metier peut extraire de manure triviale en se r6f6rant a 
I'exemple de traduction donne dans la suite, juste apres la description de la figure 2. 

Un avantage immediat du format d'objet propose est que ce format est conserve identique dans I'espace 
persistant et dans I'espace virtuel, aucune transformation de format n'est ainsi necessitee lors du chargement 
d'un objet de I'espace persistant par exemple le disque vers I'espace virtuel par exemple la m6moire centrale. 

so Seton I'invention, I'hypothfese minimale suivante est faite, a chaque classe engendrant des objets persis- 

tants est associe un identif icateur de la classe constant dans toutes les applications utilisant la classe, ainsi 
qu'a travers toutes les recompilations. Cette hypothfese minimale est indispensable pour mettre en oeuvre Tin- 
vention dans ce contexte d'objets persistants et partag6s. De manure pr6f6r6e, Pidentif icateur de la classe 
est un entier. Ainsi dans la suite, lorsqu'il est parte d'une classe Ci, i est I 'identif icateur de la classe. 

>5 De meme, de_mani6re remarquable, pour I'implantation des objets en memoire, chaque classe est asso- 

ciee a une partie qui est identique pour tous les objets appartenant a cette classe, chaque partie etant compo- 
see de deux sous-parties, une premiere sous-partie comportant un identif icateur de la classe reelle qui a en- 
gendre I'objet, identif icateur utilise comme indice dans une table de classes donnant le point d'entr6e du che- 
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min permettant la gestion de I'heritage et une seconde sous-partie renfermant I'etat def ini par la classe ayant 
engendre I'objet, I'ensemble des attributs def in is par ladite classe etant regroupe dans ledit etat. 

De cette maniere, pour implanter des objets en memoire, fe compilateur va associer a chaque classe une 
partie Pi qui est la meme pour tous les objets appartenant a cette classe. Sur ia figure 2.b f la partie P1 par 

5 exemple est la meme, qu'il s'agisse d'un objet de la classe C2 (ObjLC2) ou d'un objet de la classe C4 (Obj_C4). 
Sur la figure 2.b f chaque partie Pi apparaTt composee de deux sous-parties au lieu de trois (voir fig. 1 .b) comme 
dans I* exemple decrivant Tart anterieur. 

La premiere sous-partie correspond a I'identificateur de la classe reelle de I'objet, c'est-a-dire la classe 
qui a engendre I'objet. Cet identificateur va etre utilise comme un indice dans une table de classes, appelee 

10 et referencee sur le dessin Tabclass, qui donne le point d'entree d'un chemin permettant de gerer I'heritage. 
Pour un objet donne, compose de plusieurs parties Pi, cet identificateur est done duplique dans chaque partie 
Pi. Ainsi pour I'objet Obj_C2 I'identificateur est le meme pour les parties P1 et P2 ou pour I'objet Obj_C4 I'iden- 
tificateur est le meme pour les parties P1, P2, P3 et P4. Ce choix est necessaire puisqu'il est desire pouvoir 
referencer I'objet par Tune quelconque de ses parties, suivant le type de la variable referenpant ledit objet, une 

15 variable de type Ci pointant toujours sur une partie Pi. Ce champ de Pi est nomme "cid". 

La seconde sous-partie correspond a I'etat Ei def ini par la classe Ci. Ce champ est nomme *st", comme 
sur la figure 1.b. 

Des & present, il est possible de noter qu'il est benef icie d'un gain d'espace memoire dans un objet puisque 
seule est necessitee une information equivalente au pointeur sur la table virtuelle, les informations relatives 

20 aux pointeurs vers les parties des super-classes directes d'une classe ne sont plus requises. n peut etre mon- 
tre, maintenant, a travers le meme exemple propose avec la solution de I'art anterieur, comment gerer ('heritage 
multiple a partir de tables d'indirection ou tables virtuelles, de maniere originale par rapport au precede de 
gestion mis en oeuvre dans Tart anterieur avec C++. 

Comme dans I'exemple precedent, il est suppose une variable V de type Ci qui designe un objet Obj_Cj 

25 de type Cj, Cj etant soit la classe Ci elle-meme, soit une sous-classe de Ci. Le type Ci de la variable determine 
un ensemble de methodes applicables a I'objet qui en fait, est un sous-ensemble de I'ensemble des methodes 
qui peuvent etre appliquees a I'objet Obj_Cj, ce dernier ensemble etant def ini par le type reel Cj de I'objet De 
maniere remarquable, chaque super-classe Cj definrt un masque d'acces a la fois aux methodes applicables 
a un objet de type reel Cj ainsi qu'aux parties correspondant a ces super-classes. C'est ce qui est montre sur 

30 la figure 2.b ou la table appelee Tabclass fournit pour chaque classe Cj un pointeur vers une table de masques 
appelee Tabmask_Cj, sur fa figure Tabmask_C2 et Tabmask_C4, contenant les differents masques a travers 
lesquels un objet de type Cj, ObjLC2 ou ObLC4, peut etre manipule. En fait, un masque permet de decrire 
les differents types de variables au travers desquelles i'objet d'une classe donnee peut §tre manipulee. 
Selon ('invention une table de masques comporte autant de masques que de classes heritees plus une, 

35 la classe ayant engendre I'objet, chaque masque (chaque ligne du tableau) comporte trois champs. Le premier 
champ appele "fdeb" correspond au deplacement dd_i (dd_1 a dd_2 pour Tabmask_C2 et dd_1 a dd_4 pour 
Tabmask_C4) qui permet a partir d'un pointeur sur le debut de I'objet de calculer un pointeur sur la partie Pi 
et inversement. Le second champ appele "tabdep" correspond a un pointeur vers une table de deplacement, 
ainsi pour Tabmask_C2, vers la table de deplacement ST2.2 (deplacement d2_1) ou pour Tabmask_C4, vers 

40 les tables de deplacement ST4.2 (deplacement d2_1), ST4.3 (deplacement d3_1) et ST4.4 (defacements 
d4_1, d4_2 et d4_3). En fait, chaque table contient le ou les defacements possibles permettant de manipuler 
un objet a partir d'une variable d'une classe, de cette classe vers la ou les classes dont elle a herite. Enf in, 
un troisieme champ appele "vtbl" correspond a un pointeur vers une table virtuelle (pourTabmask_C2, les ta- 
bles virtuelles VT2.1 , VT2.2 et pour Tabmask_C4; les tables virtuelles VT4.1 , VT4.2, VT4.3 et VT4.4) dont la 

45 structure est la meme que pour la technique employee avec C++ et decrite avec la figure 1.b. 

Le deplacement correspondant au champ "fdeb" peut etre utile lore d'un chargement ou d'un decharge- 
ment explicite d'un objet de ou vers une memoire secondare. En effet, lore du chargement, c'est I'adresse sur 
le debut de I'objet qui est generalement rendue. De meme, pour le dechargement, il est souvent necessaire 
d 'avoir le pointeur sur le debut de I'objet. 

so Pour generaliser et etudier la mise en oeuvre de I'heritage a travers les structures decrites avec la figure 

2.b, il est fait Thypothese d'une manipulation d'un objet a partir d'une variable V, def inie par "Ci" *V" designant 
un objet de type reel Cj. 

Ainsi, pour le chargement d'un objet, en supposant une instruction explicite de chargement s'exprimant 
par "V=charge_objet(adresse_disque); tt ou "charge_objet" consiste a charger en memoire centrale un objet de- 
55 puis le disque, a partir de son adresse disque et retourner done son adresse virtuelle, il est necessaire de trans- 
former cette affectation dans I'expression en langage C suivante: 

(V = charge_objet(adresse_disque), V = V + Tabclass [V-»cid][i].fdeb); 
De meme, pour le dechargement d'un objet, en supposant une instruction explicite de dechargement s'ex- 
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primant par "decharge_objet(V, adresse_disque, taille);** qui decharge I'objet points par la variable V en me- 
moire centrale sur le disque d I'adresse "adresse_disque", ou "taille" signif ie taille de I'objet, il faut transformer 
cette instruction de la maniere suivante : 

decharge_objet (V - Tabclass [V-+cid]p].fdeb), adresse_disque, taille); 

5 II est k noter que la taille de I'objet peut etre aisement stockee si necessaire dans une table supplemental 

appelee par exemple "Tailleclass", I'acces d la taille se faisant alors par "Tailleclass[V-x:id]\ 

A present, concernant i'acces £ I'etat Ei d'un objet, deux cas de figure peuvent se presenter. Un premier 
cas, lorsque c'est I'etat Ei qui est accede, sachant que la variable pointe toujours sur la partie Pi, I'acces se 
fait alors simplement par "V-^st". Dans ce cas, le cout est done le meme que pour la technique C++ decrite 

10 precedemment. Le second cas se presente lorsque c'est I'etat Ej qui est accede, la classe Cj etant une super- 
classe directe ou indirecte de Ci, I'acces se fait alors par "(V+Tabdass[V^cid][i].tabdep[index (j)])->st M . 

Dans cette instruction, "index (j) n est un indice dans la table des super-classes de Ci qui est determine 
statiquement par le generateur de code, cet indice est le meme pourtous les masques associes d une classe 
donnee. L'entree de la table de deplacement (ST2.2, ST4.2, ST4.3 ou ST4.4) fournit le deplacement permettant 

is de calculer I'adresse de la partie Pj & partir de i'adresse de ia partie Pi. II est & noter que par rapport au premier 
cas, le cout est d'environ trois indirections ettrois operations arithmetiques: deuxsommes etune multiplication. 
Le cout done ici est superieur & celui de la technique C++, de deux indirections et trois operations. 

Par contre, ce cout est constant quel que soit la hierarchie d'heritage alors qu'il est necessaire d'ajouter 
une indirection en plus pour chaque niveau traverse avec la technique C++. 

20 Concernant I'appel de methode mi, ce dernier se fait toujours de la meme maniere, le cout est constant 

comme avec fa technique C++. L'appel de la methode mi se fait done par : 

"( * (Tabclass [V-^cid] [i].vtbl[index (mi)].m)) (V + Tabclass [V-^cid] [i].vtbl[index (mi)].d..." 
De maniere remarquable, la premiere expression (entre parentheses) permet le calcul de la fon^tion & ap- 
peler qui correspond & la methode mi, "index (mi)" etant def ini statiquement par le generateur de code qui as- 

25 socie d chaque classe, la table virtuelle contenant les methodes qui lui sont applicables. La seconde expression 
elle, permet le calcul de I'adresse de la partie Pi d passer comme premier parametre de la fonction en utilisant 
le deplacement def ini dans la table virtuelle d I'indice "index (mi)", une sortie de ladite table virtuelle contenant 
effectivementd'une part un pointeur vers la fonction implantant la methode correspondante et d'autre part ledit 
deplacement . Cette table virtuelle a la meme structure pour tous les masques utilises dans les sous-classes. 

30 Par contre, la fonction associee d une entree, ainsi que le deplacement peuvent etre differents d'un masque 
d I'autre puisque les methodes peuvent etre redef inies dans les sous-classes. Par exemple, la fonction m6_4 
implantant la methode m6 peut etre associee soit au deplacement d3_4 (table virtuelle VT4.3) soit au depla- 
cement d4_4 (table virtuelle VT4.4). 

Suit a present un exemple de traduction qui permettra d'encore mieux apprehender la solution proposee. 

35 Cet exemple est def ini dans le langage C++, qui met en oeuvre trois classes introduisant des liens d'heritage 
multiple. 
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class Personne { 
public : 

char Nom[40]; 

char Prenom[30]; 

long DateNaissance; 

virtual short Age Q; 



class Imposable { 
protected : 

double Re venulmposable; 
public : 

virtual void AffectRevenuImp (); 
virtual double Calcullmpot (); 

}; 

class Salarie : public virtual Personne, public virtual Imposable { 
public: 

double SalaireBrutMensuel; 
virtual void AffectRevenuImp () ; 
virtual double Calcullmpot () ; 

}; 



La traduction en tangage C de cet exemple, mettant en oeuvre les mecanismes proposes precedemment 
est la suivante : 

. Informations generates liees d I'exemple 
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25 



35 



40 



45 



typedef int (* T_meth) (char *obj); 
typedef struct { 

Tmeth m; 

long d; 

} s_vtbl; 
typedef struct { 

long cid; 

long st; 

} s Part; 
typedef struct { 

long fdeb; 

long *tabdep; 

s_vtbl *vtbl; 

} s_tabmask; 



s_tabmask *TabClass[] = 
{ 

TabmaskJPersonne, 
Tabmask_Imposable, 
^o Tabmask_Salarie 

}; 

long TailleCLass [] = 



{ 

sizeof(Personne), 

sizeof(Imposable), 

sizeof(Salarie) 

}; 



Informations relatives & la classe Personne 



so 
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#defme CIDPERSONNE (long) 0) 

typedef struct { 
long cid; 
struct { 

char Nom[40]; 

char Prenoni[30]; 

long DateNaissance; 

}st; 
} s_PPersonne 

typedef struct { 

s_PPersonne PPersonne; 
} Personne; 

s tabmask Tabmask Personne [] = 

{ 

{0, NULL, vtbl_Personne_Personne} 

}; 

#define INDEX PERSONNE AGE 0 
svtbl vtbl_Personne_Personne[] = 
{ 

{ (T_meth)Personne_Age, 0} 

}. 

. Informations relatives d la classe Imposable 

#define CIDIMPOSABLE ((long) 1) 
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typedef struct { 
long cid; 
struct { 

double Revenulmposable; 
} st; 

} sPImposable; 

typedef struct { 

s_PImposable PImposable; 
} Imposable; 

s tabmask Tabmaskjtaiposable [] = 

{ 

{0, NULL, NULL}, 

{0, NULL, vtbl Imposable_Imposable} 

}; 

#defme INDEX_IMPOSABLE_AFFECTREVENUIMP 0 
#define INDEXIMPOSABLECALCULIMPOT 1 
s vtbl vtbl_Imposable_Imposable Q = 

{ 

{(T meth) Imposable_AffectRevenuImp, 0}, 
{(T_meth)Imposable_CalculImpot, 0} 

}; 

. Informations relatives d la classe Salarie 

#defme CDD_SALARIE ((long) 2) 

typedef struct { 
long cid; 
struct { 

double SalaireBrutMensixel; 
} st; 
} s_PSalarie; 



typedef struct { 
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sPSalarie PSalarie; 
sJPPersonne PPersonne; 
sPImposable PImposable; 
} Salarie; 

s_tabmask Tabmask_Salarie[] = 
{ 

{sizeof(s_PSalarie) 5 NULL, vtbl Salarie Personne}, 
{sizeof(s_PSalarie) + sizeof(s_PPersonne), NULL, 
vtbl_Salarie_Imposable} , 
1S { 0, tabdepSalarieSalarie, vtblSalarieSalarie } 

}; 
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20 



25 



30 



fcdefine IN DEX_S ALARIE_AGE ((long) 0) 
#define INDEX SALARIE AFFECTREVENUIMP ((long) 1) 
#defuie INDEX SALARIE CALCULIMPOT ((long) 2) 
s_vtbl vtbl_Salarie_Personne[] = 

{ 

{ (T_meth)Personne_Age, 0) 

}; 

s vtbl vtbl Salarie lmposable [] = 

{ 

{(T_meth)Salarie_AJfectRevenuImp, -sizeof (s PPersonne) 

sizeof (s_PSalarie) }, 
35 { T _meth)Salarie_CalculImpot, -sizeof (sJPPersonne) 

sizeof (s_PSalarie)} 

}; 

s vtbl vtbl_Salarie_Salarie [] = 
{ 

{ (Tjneth) Personne Age, sizeof (s_PSalarie) } 
{ (T meth) Salarie AffectRevenuImp, 0}, 
{ (T_meth) Salarie CalculImpot, 0} 

}; 



40 



45 



so f| est a remarquer que chaque fonction est prefix 6e par le nom de la classe qui la def init. En effet, comme 

les m6thodes sont traduites sous forme de fonctions C et qu'une m 6th ode peut §tre surcharg6e dans une sous- 
classe, il est necessaire de pre fixer les noms des fonctions pour distinguer deux mises en oeuvre differentes 
d'une meme m6thode. 

A partir de la traduction ci-dessus, il est possible de montrer un exemple d'utilisation de structures ainsi 
55 def inies. II est suppose que le morceau de code suivant est a traduire : 
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Personne *p; 
Salarie *s; 
short a; 



p = s 

a = s-»Age() + p-»Age(); 
strcpy (s-^Nom, "toto"); 
s-»SalaireBrutMensuel = 10000; 

La traduction est alors la suivante : 

char *p; 
char *s; 
short a; 

P = (s + Tabclass[((s_Part *)s)->cid] [CIDSALARIE] 
tabdep [CIDPERSONNE]); 

a = ((Tabclass[((s_Part *)s)->cid] [CID SALARIE] . vtbl 
[INDEXS AL ARIEAGE] .m(s + Tabclass [s_Part *)s)^cid] 
[CIDSALARIE] . vtbl [INDEXS AL ARIEAGE] . d)) + 
Tabclass[((s_Part *)s)-»cid] [CID PERSONNE] vtbl 
[INDEX_PERSONNE_AGE].m(s + Tabclass [(s_Part *)s)-»cid] 
CID_PERSONNE] . vtbl [INDEX PERSONNE AGE] . d))); 
strcpy (((s_PPersonne *) (s + Tabclass [((s_Part 

*)s)-vcid] [CID SALARIE] . tabdep [CID_PERSONNE])) -> 
st.Nom, "toto"); 

((s_PSalarie *) s) -» st.SalaireBrutMensuel = 10000; 

La solution proposee selon la presente invention resout done tous les problemes lies a la gestion de I'he- 
ritage multiple dans un contexte d'objets persistants et partag6s. tel que par exemple un couplage des objets 
dans un segment de memoire partagee UNIX. Elle s'applique avantageusement au langage C++ lorsque ce 
dernier est rendu persistant mais elle peut egalement s'appliquer a tout autre langage ou systeme a objets 
persistants qui supportent les memes concepts d'heritage. Cette solution est aisee et efficace a mettre en 
oeuvre, la plus grande partie du traitement etant effectuee statiquement au moment de la compilation. Le che- 
min d'adressage impose peut etre applique de nouveau sans operation prealable surl'objet en train d'Stre char- 
ge. Conformement a I'idee de I'invention. la structure de I'objet est d'une part independante du code de la clas- 
se et done de I'adresse a laquelle il va etre implante et d'autre part independante du code de la classe aui a 
engendre cet objeL 
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Revendications 

1 . Proc6d6 de gestion de ('heritage multiple dans un systeme ou un langage a objets persistants et partag6s 
caracteris6 en ce que le format d'un objet est maintenu inchange lors du chargement dudit objet de I'es- 
pace persistant vers I'espace virtuel, chaque classe engendrant un objet etant assoctee a un identif icateur 
de la classe constant dans toutes les applications utilisant la classe ainsi qu'a travers toutes les recorrv 
pilations, la structure de Tobjet 6tant ainsi indSpendante de I'adresse d'implantation en m6moire et du 
code de la classe g6n6rant cet objet, alors qu'un chemin d'adressage permettant la gestion de ('heritage 
est emprunte au travers de differentes tables. 
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2. Proc£de de gestion de ('heritage multiple selon la revendication 1, caract6ris6 en ce que pour I'implanta- 
tion des objets en m6moire, chaque classe est associ6e a une partie qui est identique pour tous les objets 
appartenant a cette classe, chaque partie etant compos6e de deux sous-parties, une premiere sous- 
partie comportant un identif icateur de la classe reelle qui a engendre Tobjet, identificateur utilise comme 

15 indice dans une table de classes donnant le point d'entr6e du chemin permettant la gestion de ('heritage 

et une seconde sous-partie renfermant I'etat defini par la classe ayant engendre I'objet, Tensemble des 
attributs d£f inis par ladite classe etant regroupe dans ledit etat. 

3. Proc£d£ de gestion de ('heritage multiple selon la revendication 2, caracterise en ce que I'identif icateur 
20 de classe associ£ a chaque classe est un entier. 

4. Proced6 de gestion de I'heritage multiple selon la revendication 2 ou 3, caract£ris6 en ce que la table de 
classes fournit pour chaque classe un pointeur vers une table de masques contenant les differents mas- 
ques a travers lesquels un objet peut §tre manipule, chaque masque etant defini par une classe hSritee 

25 et autorisant Tacces a la fois aux methodes permettant de manipuler I'objet ainsi qu'a la partie associee 

a ladite classe h6ritee. 

5. Proc6de de gestion de I'heritage multiple selon la revendication 4, caracterisg en ce que, une table de 
masques comporte autant de masques que de classes heritees plus une, la classe ayant engendre 1'objet, 

30 chaque masque comportant trois champs, un premier champ correspondant au deplacement permettant 

a partir d'un pointeur sur le debut de I'objet de calculer un pointeur sur la partie associ6e a la classe ayant 
engendre I'objet et inversement un second champ correspondant a un pointeur vers une table de depla- 
cement qui donne le deplacement permettant de calculer I'adresse de la partie assoctee a I'objet concern^ 
pour acceder a I'etat dudit objet et un troisieme champ correspondant a un pointeur vers une table virtuelle 

35 qui permet de determiner la methode a appeler. 

6. Proc6d6 de gestion de Theritage multiple selon la revendication 5, caracteris6 en ce que, lors de f'appel 
d'une methode, il est calcule une fonction a appeler qui correspond a la methode concernee, un index 
etant pour cela defini statiquement parle generateur de code qui associe a chaque classe la table virtuelle 

40 contenant les methodes qui lui sont applicables, alors qu'une entree de ladite table contient un pointeur 

vers la fonction implantant la methode correspondante et un deplacement permettant de calculer I'adres- 
se de la partie de I'objet a passer comme premier parametre de ladite methode. 

45 



so 



55 
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